Scrum Guide 一開始在 2010 年時, 提到 Scrum 是針對專案的作法.

Scum is a framework for a project whose horizon is no more than one month long, where there is enough Tip When a Team begins Scrum, two weeks Sprints allow it to learn without wallowing in uncertainty. Sprints of this length can be synchronized with other Teams by adding two increments together. complexity that a longer horizon is too risky.
資料來源：Scrum Guide 2010

但是到了 2013 年時, Scrum Guide 改口說 Scrum 是針對產品的開發方法.

Scrum is a process framework that has been used to manage complex product development since the early 1990s.
資料來源：Scrum Guide 2013

為什麼會有這樣的轉變呢? 主要是以產品形式來開發, 會比以專案形式開發, 有著更多的好處. 讓我們一一道來吧

(1) 經費

專案通常在一開始就要編好預算, 在執行過程中公司往往會確認你是否照著預算來執行. 如果花不完, 下次可能就不會給你這麼多, 所以很多時候可能是為花而花, 而不是看真的是否需要. 但是如果花不夠, 要再擴增預算, 會經過層層嚴格的 刁難 審查, 才能拿到那筆錢. 因此導致很多組織一開始就先編好編滿, 避免之後很難再加預算.

但是以產品為主的開發方式, 它會根據業務結果來規劃預算, 如果這個產品能夠多賺錢, 它便會持續投資更多經費, 所以鼓勵的是團隊要去多交付價值, 而非是形式的花費.

(2) 時程

專案是有時程限制的, 在這段時程內會有資源和預算進來, 等到時程到了以後, 便沒有資源和預算來繼續處理. 如果真的之後還有事情進來, 例如修改些小功能, 幫客戶修復某些錯誤, 除非客戶願意再增加費用, 要不能你只能夾在另外的專案偷偷做. 否則大概就是一律拒絕, 跟客戶說專案已經結束.

可以以產品為主的作法, 因為產品通常有生命週期, 而且這個週期大約可能要數年, 如果火紅的產品可能到十幾年, 因此這段期間都還繼續正常調整功能或者是修復錯誤, 對客戶來說感受比較好.

(3) 組成團隊

傳統專案的團隊組成, 大多是依任務臨時編制而成的. 如果這個專案需要哪類型的人, 便會召集相關的好手進來參加. 因此每次你需要花時間適應新的團隊成員, 但可能等你適應之後, 這個專案也差不多要結束了, 可能等到後期工作的合作才比較順利. 更恐怖的有可能你能力很強, 同時參加數個專案, 因此每天你需要和不同的新朋友打交道, 新工作和新同事會讓你疲於奔命.

至於產品為主的團隊, 團隊成員會在一段時間內是固定的, 因此當你適應新的同事後, 便有一段長的時間一起工作, 讓這樣高默契高生產力可以維持一段時間. 也讓知識的學習和累積可以發生.

(4) 成功定義

對於專案的成功, 大家一定聽過”如期, 如值, 如預算”, 如果無法達到這三點, 就是失敗的專案. 尤其時傳統的組織或是老一輩的專案經理, 都是這樣來思考的. 對於 1.0 專案, 基本上連方向都不知道, 不太可能可以做到. 如果你為了做這三點而朝令夕改, 可能也會讓成員對你很不滿.

那以產品為主的進行方式, 它考量的點便不同. 認為要能賺錢, 要能持續交付價值給客戶, 幫助客戶成功, 這樣才算成功. 因此, 產品為主的思考點是客戶成功, 而專案為主的思考點是自己成功.

(5) 優先順序

專案為主的優先順序, 會以計畫為主來進行安排, 就是依照事先規劃好的方式進行, 如果有意外進來, 還要進變更控制委員會( Change Control Board, CCB) 討論, 因此進度上的反應可能無法及時. 如果你支援多個專案, 這時候就會很痛苦, 因為這些專案的優先順序可能相互是衝突的, 你很難討好全部, 但是又不得不都去處理.

產品為主是基於客戶和收益為主來考量優先順序. 所以當客戶需求進來時, 會根據整體收益來考量, 看看哪個對客戶最有幫助, 或是可以賺最多錢, 團隊就先處理哪個. 而不是只照計畫進行, 或者是每個都做.

根據上述種種理由, 產品開發為主會比專案為主的方式為宜. 所以LeSS 也是一個以產品為主的作法. LeSS 強調只有一個產品負責人, 一份產品待辦列表, 因此如何決定產品對於 LeSS 相當關鍵. 為什麼決定產品很重要呢? 讓我們來看看以下事情：

(1) 客戶是誰

知道客戶是誰, 才能知道他們要什麼, 哪些需求要優先處理. 很多時候你會發現到你的產品沒有客戶, 或者客戶是內部另一個產品, 或者是內部很多團隊, 這時候代表你只是一個子系統, 似乎不合適當成 LeSS 的一個產品. 你的視野可能還是在比較小的範圍.

(2) 產品待辦列表

產品待辦列表要包含什麼, 是跟產品有很大的關係. 如果要做 Word, 就不會把 Excel 的功能拿進來做. 如果是 Word和 Excel 整合的部分, 也可能需要看是誰依賴誰, 而決定是否先做.

另外, 如果你列在產品待辦列表, 完成之後無法單獨展示, 或者找不到客戶有興趣來看展示, 這也是要思考所找的產品範圍是否合適.

(3) 被挑選的團隊

產品的範圍決定所使用技術, 元件和領域知識. 這些東西不是人人都會的, 所以一旦決定後就會限制你可以找哪些團隊或是人來參與 LeSS 開發.

(4) 產品負責人

同理, 產品的範圍所涵蓋的市場, 客戶, 和領域知識, 也不是每個品負責人都熟悉, 或者都合適, 所以也會限制產品負責人的人選.

總之, 產品的範圍將會牽動很多東西. 可是一般在開始導入 LeSS 時, 大多只是想到要組Feature Team, 要了解 LeSS 流程, 事實上, 找出合適的產品範圍才是第一件大事.

如何來決定產品範圍呢? LeSS 會建議比較寬鬆的範圍會比較好, 為什麼呢?

(1) 更好的優先順序

當產品範圍比較寬鬆, 原先多個產品就會變成一個, 多個產品待辦列表也會變成一個. 因為都變成一個, 因此要合起來考量, 在有限的時間和資源下, 我們該把重心放到哪邊, 而不是每個東西都做. 這個檢視是一起攤在陽光下, 並非密室交易, 針對客戶或收益來決定哪個先做.

(2) 避免做重複的事

每個需求都會放到產品待辦列表中, 然後進行 Product Backlog Refinement, 並且每個團隊都可能領到. 並且在 Sprint Planning 2時, 也會有多團隊在進行. 因此如果有重複的事情, 很容易就會被發現到. 避免各個團隊做出重複的功能或元件.

(3) 共同處理相依的問題

如果是不同產品之間有相依或關聯性時, 你可能需要有個協調的角色, 幫忙牽線大家一起來討論, 並且追蹤是否有照表操課. 真的把事情給完成. 如果是同一個產品範圍, 有發現相依的狀況, 在 PBR 和 Sprint Planning 中便會把有關聯的部分一起討論, 並且是由團隊自己來進行, 不用在找額外的角色來處理.

雖然產品的範圍寬鬆一點有這些優點, 你也無法讓整個公司都變成一個產品就好, 在現實生活中, 還是有會有些限制在. 以下就是一些可能的限制因素：

(1) 市場/客戶類別

高端市場和大眾市場, 企業用戶和個人用戶, 功能設計的重點不相同, 產品的願景也可能不一樣, 所以兩邊所帶進來的需求可能很難合在一起, 這時候或許不就容易變成一個產品.

(2) 外包還是公司團隊

駐點團隊可能有點機會可以一起跑 LeSS. 但是對於外包公司, 他們可能同時接好幾個專案, 他們不見得可以跟你合在一起看優先級, 這時候跑 LeSS 就會同床異夢.

(3) 你能控制的部門或是需要和其他部門/主管協作

如果你們不同老闆, 我想應該很難指揮的動, 更不用說要之後要做組織重整, 團隊成員的直屬關係要換, 基本上對方老闆不會同意.

(4) 共同的功能或領域知識
在同一個產品下的系統, 應該會有不少共同的部分. 如果彼此都沒有關聯, 每個團隊都要重新學習其他團隊的東西, 這樣就算合在一起, 也是各做各的. 並且需要花很大的代價, 才能讓大家去熟悉對方的東西.

所以在定義產品範圍時, 不只要比較寬鬆去看待, 也要考慮實際的限制, 是否合適把這些東西都合在一起. 當你發散和收斂的因素都考量後, 你就會得到一個初始的產品定義和範圍. 之所以稱為初始, 是因為這個範圍之後可能會變. 只要前面考量的因素有改變, 自然產品範圍就會跟著調整.

所以根據 LeSS 中的指南, 你可以用以下流程和問題來思考如何定義你的產品：

(1) 盡可能地發散產品範圍

詢問客戶, 他們認為我們的產品是什麼
詢問客戶, 他們會怎麼使用我們的產品, 解決什麼問題
詢問團隊, 我們之間有什麼共同要解的問題
詢問團隊, 我們之間有什麼共用的元件
詢問團隊, 我們之間有什麼類似或相同的功能
詢問團隊, 我們之間有什麼類似或相同的領域知識

(2) 根據現實來收斂產品範圍

詢問團隊, 我們之間市場/客戶有沒有什麼交集
詢問團隊, 我們之間是否有相同的目標或願景
詢問團隊, 我們之間是否可能做組織重整
詢問團隊, 我們之間上下屬關係, report line 關係是什麼
詢問團隊, 我們之間有什麼類似或相同的領域知識

(3) 定義初始的產品範圍

考量以上問題後, 大致上可以產生一版產品範圍出來

接著, 我們用一個範例, 讓你看看產品範圍大致上是怎樣定義的. 這是一個簡單的思考過程, 實際上的討論一定比這個複雜很多.

金融產品通常是很複雜, 往往牽涉到許多系統和團隊. 例如在徵授信管理, 通常的工作流程會經過進件, 徵信, 擔保品鑑估, 授信等流程. 這些可能需要進件管理系統, 信用評等系統, 擔保品管理系統, 和貸後管理系統來幫忙.

對於用戶而言, 他們覺得我們的產品會是什麼? 應該是想要能提供完成交易的解決方案, 也就是一個端到端的解法. 他們不會知道我們內部有分成哪些系統. 他們只要我們幫她解決問題. 因此, 我們需要盡量以客戶為主的方式去切產品範圍, 不是以我們自己系統好做, 或是現有團隊結構去切. 因此, 如果是分成進件管理系統, 信用評等系統, 擔保品管理系統, 和貸後管理系統 這四個產品, 對用戶來說它就很麻煩, 他要去四個地方使用, 才能完成事情. 如果這中間需要資料匯出匯入轉檔等功能, 還要等某個產品團隊有空才能改進. 這樣客戶的觀感會不佳.

那進件管理系統, 信用評等系統, 擔保品管理系統, 和貸後管理系統, 是否有些共用元件, 基礎設施, 或者哪些功能很類似或重複, 以及是有相關的領域知識. 如果這幾個系統中間有很多共用的東西, 要合併成一個產品就會比較容易一點, 因為有些東西是原本各自團隊都懂. 如果你發現這四個系統都沒有任何關聯之處, 要合併成一個產品, 就代表大家一開始都不懂對方的東西, 要去接產品待辦列表內的需求時, 也只能先接自己熟的, 這樣要跑 LeSS 難度就很高.

另外, 如果這四個系統, 都是在你所管轄的範圍內, 或者這些系統的部門主管都是同一個人, 這樣要調動去實施 LeSS, 成功的機會就會比較高. 因為你需要去溝通的人比較少, 或者本來你就是他們的老大, 比較可以從行政命令開始. 當然啦, LeSS 的導入原則還是從志願開始. 但是這樣複雜度一開始就比較低.

當然有可能其中某個系統是外包公司幫忙做的, 或者是買現成的系統來使用的, 這時候就會更複雜, 因為你需要和公司外合作, 如果再加上不同語言, 不同地區的時差, 這樣要合作跑 LeSS, 起手式就沒有那麼單純了.

以上就是在定義產品範圍時, 你可能進行方式和考量. 希望可以幫助你決定 LeSS 的產品範圍.